All software applications that interact with humans in some way need to have a user interface (“UI”). A UI is a collection of UI controls laid out on a window/surface in such a manner as to provide the user access to the application's functionality. Menu bars, toolbars, wizards, dialog boxes, tabs, panels, text fields, radio buttons, checkboxes, and the all-familiar buttons are examples of UI controls.
When a developer implements a particular UI, a UI framework is selected which helps with the drawing, layout, and input routing for the UI about to be built. As the developer builds the UI, the controls are typically grouped in panels, tabs, dialog boxes, child windows, all the way up to the main window, effectively creating a hierarchy of UI controls.
Traditionally, the code written by the developer to describe the entire hierarchy of UI controls ends up describing the nodes of a tree commonly referred to as a UI control tree. There are two existing problems that a UI framework faces with this approach: the code used to express the UI control tree tends to be bulky because it works much like a document object model; and it can take up a lot of space in memory and in persistent storage (e.g., on disk). In addition, when it comes time for the UI to be rendered on screen, it is costly to validate and interpret this code/tree every time the UI needs to loaded and painted on screen.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor to be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.